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Commissioner for Patents: 

This Appellant's Reply Brief is being filed under 37 CFR 41.41 (effective date of 
September 13, 2004) in response to the Examiner's Answer mailed on October 5, 2010, which in 
turn was mailed in response to the Appellant's Brief filed on May 7, 2010. 

I. Summary of the Examiner's Answer 

The Examiner's Answer maintained the rejection of claims 1-5, 9-34, 36, 43-50, 
and 52 under 35 U.S.C. § 103(a) as allegedly being unpatentable over Craig (U.S. Patent No. 
7,031,314) in view of Peiffer (U.S. Patent No. 7,055,028). The Examiner's Answer further 
maintained the rejection of claims 6-8, 35, and 51 under 35 U.S.C. § 103(a) as allegedly being 
unpatentable over Craig in view of Peiffer, and further in view of Susai (U.S. Patent No. 
6,954,780). 
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In sections 27-28 subtitled "Response to Argument" (pages 11-16) of the 
Examiner's Answer, the Examiner presented arguments to support maintaining the rejections of 
the claims. At least some of these arguments by the Examiner will be addressed below. 

It is noted herein for the record that while only some of the Examiner's arguments 
from the Examiner's Answer are being addressed below, none of the appellant's previous 
arguments presented in the Appellant's Brief are being waived or withdrawn, by not further 
raising or otherwise discussing herein such previously submitted appellant's arguments. 
Furthermore, to the extent that some of the Examiner's arguments in the Examiner's Answer are 
not specifically addressed herein, such non-addressing of these Examiner's arguments should not 
be interpreted as a concession by the appellant that the Examiner's arguments have merit-rather, 
such non-addressing is to avoid redundant resubmission herein of the appellant's arguments that 
have already been made of record in the present appeal. 

II. Discussion of arguments presented in the Examiner's Answer 
A. Independent claim 1 

Independent claim 1 was addressed in detail in the Examiner's Answer, and is 
reproduced in part below (emphasis ours): 

"receiving at said network device via said client-side connection a 
communication that signals said server-side connection to close; and 

maintaining persistent, by said network device, at least the 
server-side connection in response to said communication received via 
said client-side connection." 

It was argued in substance in the Appellant's Brief that Craig did not teach at least 
the recitation of "maintaining persistent. . .at least the server-side connection in response to said 
communication [that signals said server-side connection to close]." To support such argument, 
the Appellant's Brief cited column 17, line 57 to column 18, line 1 1 of Craig, which is reproduced 
below (emphasis ours): 

"After the transaction state is complete, the communication session 
may then enter into an update state (as indicated generally at 440) that 
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closes the communication session and a close state (as indicated generally 
at 450) that closes the connection between the wireless client 110 and the 
server 180 . . During the close state, however, the operating system and 
networking stack of the service module 190 responds to messages 
received by the wireless client 110 in order to close the client-side 
connection. The operating system and networking stack then notifies the 
service application that the client-side connection has been closed, and the 
service application responds by initiating closure of the server-side 
connection. The operating system and networking stack of the service 
module 190 then engages in conventional closure handshakes with the 
server 180 in order to close the server-side connection as indicated 
generally at 455." 



Thus, from the above-quoted passage, it is abundantly clear that Craig explicitly 
teaches that he "close[s] the server-side connection" in response to a communication (e.g., Craig's 
above-described "conventional closure handshakes" and/or "...responds to messages received by 
the wireless client 1 10") that signals the server-side connection to close. 

Despite the above explicit teachings of Crag's column 17, line 57 to column 18, 
line 1 1 that he closes his server-side connection, rather than maintaining persistent as recited in 
claim 1, the Examiner's Answer still continues to rely on the same passage of Craig in order to 
support the rejection of claim 1. Specifically, the Examiner's Answer alleged the following in 
section 28 (page 12): 

"(...column 17 line 66 to column 18 line 11, during the close state the 
service module responds to communication received by the wireless client 
in order to close connection that[sic] closing the client-side connection and 
maintaining the server-side connection until a FIN signal received from 
the wireless client see reference nos. 450 and 455 of figure 4." 



However, it is submitted herein that the above-quoted interpretation of Craig by 
the Examiner actually supports the appellant's arguments, rather than being a rebuttal against the 
appellant's arguments. For example, the above-quoted interpretation clearly states that the 
server-side connection is closed (rather than maintained persistent) in response to "a FIN signal 
received from the wireless client." 

Furthermore, the Examiner is incorrect in interpreting that Craig teaches 
"maintaining the server-side connection." Instead, Craig teaches from his column 17, line 57 to 
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column 18, line 11 and Figure 4 (cited by the Examiner) that Craig closes his server-side 
connection in response to closing his client-side connection. Craig teaches in column 17, line 57 
to column 18, line 11 that "the client-side connection has been closed, and the service application 
responds by initiating closure of the server-side connection" (emphasis ours), and Figure 4 shows 
that the server-side connection is closed at 455 after the client-side connection is closed at 450 
during the "conventional closure handshakes"— there is no "maintaining persistent. . .at least the 
server-side connection in response to said communication [that signals said server-side 
connection to close]" in Craig. 

Section 28 (pages 12-13) of the Examiner's Answer further alleges that certain 
passages in Pfeiffer' s columns 9-10 teach "maintaining] persistent connections." It is true that 
these passages of Pfeiffer discuss maintaining persistent connections — however, such teachings in 
these passages of Pfeiffer are different than what is recited in claim 1, and such teachings do not 
support the Examiner's rejection of claim 1. 

For example and as previously explained in the Appellant's Brief, column 9, lines 
62-63 of Peiffer explicitly teaches that the persistent connection is maintained open "unless 
explicitly commanded to close" (emphasis ours). Therefore, Peiffer will also CLOSE (rather than 
"maintaining persistent" as recited in claim 1) the server-side connection in response to a 
communication that signals ("explicitly command[s]") the server-side connection to close. 

Thus, Peiffer does not cure the deficiencies of Craig with respect to the recitations 
in claim 1 of "receiving at said network device via said client-side connection a communication 
that signals said server-side connection to close; and maintaining persistent, by said network 
device, at least the server-side connection in response to said communication received via said 
client-side connection." Accordingly, claim 1 should be allowed. 

B. Dependent claim 9 

Dependent claim 9 recites, inter alia, the following (emphasis ours): 

'wherein maintaining persistent at least the server-side 
connection in response to said communication received via said client- 
side connection includes. 

modifying, by said network device, a header in the 
communication from a format that signals the server-side connection to 
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close to a format that is unrecognizable by a server coupled to said 
server-side connection, to cause the server to ignore the modified header." 



In section 28 (page 14) of the Examiner's Answer, the Examiner alleged that 
Craig's column 11, line 45 to column 12, line 3 teaches the following (emphasis ours): 

"if the packet does not match a classification rule (a format 
unrecognizable by a server), then modifying the packet header to replace 
the original information to terminate the packet and ignore the modified 
header by the server. . . " 



However, the above interpretation of Craig by the Examiner is inaccurate. Craig 
instead teaches the following in his column 1 1, line 45 et seq. (emphasis ours): 

"If the packet does not match a classification rule 330, the 
classifier 325 either drops the packet, returns the packet to the IP filter 
layer 322 without modification, or redirects the packet to a default service 
application. If the packet matches a classification rule associated with 
the service application 250, however, the classifier 325 redirects the 
packet to the service application 250 associated with the classification 
rule by modifying the packet header to replace the original destination 
address and destination port with a destination address and destination 
port associated with the service application 250. The classifier 325 then 
returns the modified packet to the IP filter layer 322, which forwards the 
modified packet to the IP and TCP layers 335, 340 for processing. The 
classifier 325 also stores the original packet header information (along 
with the redirected destination address and destination port) within a 
connection table 332 to enable the classifier 325 and the service 
application 250 to access the original packet header information at a later 
time, as will be described hereinbelow." 



Assuming arguendo and hypothetical /y that the Examiner is correct in that Craig's 
"does not match a classification rule" is equivalent to "a format that is unrecognizable by a 
server," then the cited passage of Craig still does not support a rejection of claim 9. Claim 9 
recites "modifying... a header... to a format that is unrecognizable by a server" (e.g., 
modifying-^unrecognizable format), whereas the above-quoted passage of Craig is opposite or 
otherwise different from the recitations of claim 9. As taught by Craig above, he first does not 
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"recognize" the packet and then proceeds "without modification" (e.g., unrecognizable-^no 
modifying). 

Furthermore, in the event that Craig recognizes the packet (if the packet matches a 
classification rule), then the above-quoted passage of Craig indisputably teaches that he performs 
a modification of the packet to a format that is recognizable by a server ("forwards the modified 
packet to the IP and TCP layers 335, 340 for processing"). Thus in this situation, Craig performs 
a process that involves recognizing->modifying->recognizable format, rather than 
modifying-^unrecognizable format as represented in claim 9. 

Accordingly, since Craig singly or in combination with the other references does 
not teach the recitations of claim 9, claim 9 is allowable. 

C. Dependent claim 1 1 

Dependent claim 1 1 recites, inter alia, the following (emphasis ours): 

"wherein maintaining persistent at least the server-side 
connection in response to said communication received via said client- 
side connection includes. 

changing, by said network device, a HTTP version value 
indicated in the communication to another HTTP version value that is 
recognizable by a server, coupled to said server-side connection, as being 
associated with a persistent connection" 

In section 28 (page 15) of the Examiner's Answer, the Examiner alleges that 
column 9, lines 20-48 of Pfeiffer teaches the recitations of claim 1 1 . Specifically, the Examiner 
alleges that Pfeiffer teaches "determining the type of the request and use that information to 
match proper version of HTTP request with server-side socket, which is functionally equivalent to 
the claimed limitations and implies that changing a HTTP version value that is recognizable by a 
server." 

The Examiner's reliance on Pfeiffer to support the rejection of claim 1 1 is without 

merit. 

The cited passage of Pfeiffer merely describes "determining the type of the 
request" and mentions nothing regarding "changing a HTTP version value indicated in the 
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communication. .." as recited in claim 11. Stated in another way, "determining" a HTTP version 
value is not the same as, not functionally equivalent to, or does not imply "changing" the HTTP 
version value. Indeed, Pfeiffer explains in the cited passage that he designates separate sockets 
for HTTP 1.0 requests and for HTTP 1.1 requests, and then routes requests to the appropriate 
socket depending on the request's determined HTTP -type. Clearly therefore, Pfeiffer is not 
changing the HTTP version value of the request—he is just sending the request (without any 
"changing") to the appropriate socket that is designated to handle that type of request. 

Hence, since Pfeiffer singly or in combination do not teach the recitations of claim 
11, claim 11 is allowable. 

D. Other claims 

The other claims are allowable by virtue of the reasons set forth in the Appellant's 
Brief and also by virtue of reasons analogous to those presented above. 

In view of the arguments as set forth above and in the Appellant's Brief, the 
Examiner's rejections should be withdrawn. 

Respectfully submitted, 
Schwabe, Williamson & Wyatt 

/Dennis M. de Guzman/ 

Dennis M. de Guzman 
Registration No. 41,702 

1420 Fifth Avenue, Suite 3400 
Seattle, Washington 98101 
Phone: (206)407-1574 
Fax: (206)292-0460 
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